UTILITY 
PATENT APPLICATION 
TRANSMITTAL 

(Only for new nonprovisional applications under 37 CFR 1 53(b)} 



Attorns y Docket No. 


200023US2RD 


First Inventor or Application Identifier 


Satoshi ITO 



Title 



ELECTRONIC CATALOG MAINTENANCE SYSTEM FOR ENABLING (^JT- 
OF-STANDARD ELECTRONIC CATALOG CHANGES cu^^ 




APPLICATION ELEMENTS 

See MPEP chapter 600 concerning utihty patent application contents 



ADDRESS TO: 



m 

Assistant Commissioner for Patents • 
Box Patent Application ^ 
Washington, DC 20231 «> 



Fee Transmittal Form (e.g. PTO/SB/17) 

I* in (Submit an original and a duplicate for fee processing) 



= ^ Specification 



Totai Sheets 



41 



Draw\ng{s) (35 U.S.C. 113) Total Sheets 



i o 



34 

(Formals) 



Oath or Declaration Total Pages | 3 

■ Newly executed (original) 

PI Copy from a prior application (37 C.F.R, §1 .63(d)) 
i-j /fr^r .'^+;on / divisional w/ box 1 6 connplefed) 



(for continuation 

i. □ DELETION OF INVENTOR(S) 

Signed statement attaclied deleting inventor(s) named in 
thie prior application, see 37 C.F.R. §1. 63(d)(2) and 
1.33(b). 



7. 

8. 

9. 
10. 
11. 

12. 

13. ■ 

14. ■ 

15. □ 



37 C.F.R. §3. 73(b) Statement 

(when there is an assignee) 



ACCOIVIPANYING APPLICATION PARTS ^ 

Assignment Papers (cover sheet & document{s)) 
Application Data Sheet. See 37 CFR 1 .76 

□ Power of Attorney 

English Translation Document (if applicable) 

Information Disclosure 
Statement (IDS)/PTO-1449 

Preliminary Amendment 

White Advance Serial No. Postcard 

Certified Copy of Priority Document(s) (1 ) 

(if foreign priority is claimed) 

Applicant claims small entity status. 
See 37 CFR 1.27 



P, Copies of IDS 
^ Citations 



□ CD-ROM or CD-R in duplicate, large table or Computer 
Program {Appendix) 

□ Nucleotide and/or Amino Acid Sequence Submission 
(if applicable, all necessary) 

a. □ Computer Readable Form (CRF) 

b. Specification or Sequence Listing on: 

i. □ CD-ROM or CD-R (2 copies); or 

ii. □ Paper 

c. □ Statements verifying identity of above copies 



16. ■ Other: Notice of Phority 



16. If a CONTl N U 1 N G AP PLICATI ON , check appropriate box, and supply the requisite information below: 

a Continuation □ Divisional □ Continuation-in-part (CI P) of prior application no.: 

Prior application in forma fion: Exa miner: GroupArtUnit: 

For CONTINUATION OR DIVISIONAL APRS only: The entire disclosure of the pnor application, from which an oath or declaration is supplied under Box 4b, is 
:onsidered a part of the accompanying continuation or divisional application and is hereby incorporated by reference. The incorporation can only be relied upon 
/vhen a portion has been inadvertently omitted from the submitted application parts. 



17, Amend the specification by inserting before the first line the sentence: 
□ This application is a □ Continuation □ Division □ Continuation-in-part (CIP) 
of application Serial No. Filed on 

n This application claims priority of provisional application Serial No. Filed 



18. CORRESPONDENCE ADDRESS 




(703)413-3000 
FACSIMILE: (703)413-2220 



Name: 


Marvin J. Spivak 


Registration No.: 


24,913 


Signature: 






Name: 




Registration No.: 





Docket No. 200023US2RD 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

INVENTOR(S) Satoshi ITO 
SERIAL NO: New Application 
-FILING DATE: Herewith 



FOR: 



ELECTRONIC CATALOG MAINTENANCE SYSTEM FOR ENABLING OUT-OF- STANDARD 
ELECTRONIC CATALOG CHANGES 



FEE TRANSMITTAL 



ASSISTANT COMMISSIONER FOR PATENTS 
WASHESFGTON, D.C, 20231 



FOR 


NUMBER 
FILED 


NUMBER 
EXTRA 


RATE 


CALCULATIONS 


TOTAL CLAIMS 


24 - 20 = 


4 


X $18 = 


$72.00 


INDEPENDENT CLAIMS 


3 - 3 - 


0 


X $80 = 


$0,00 


□ MULTIPLE DEPENDENT CLAIMS (If applicable) 


+ $270 = 


$0.00 


□ LATE FILING OF DECLARATION 


+ $130 = 


$0.00 


BASIC FEE 


$710.00 


TOTAL OF ABOVE CALCULATIONS 


$782.00 


□ REDUCTION BY 50% FOR FILING BY SMALL ENTITY 


$0.00 


□ FILING IN NON-ENGLISH LANGUAGE 


+ $130 = 


$0.00 


□ RECORDATION OF ASSIGNMENT 


+ $40 = 


$0.00 


TOTAL 


$782.00 



□ Please charge Deposit Account No. 15-0030 in the amount of A duplicate copy of this sheet is enclosed. 

■ A check in the amount of $782.00 to cover the filing fee is enclosed, 

■ The Commissioner is hereby authorized to charge any additional fees which may be required for the papers being filed 
herewith and for which no check is enclosed herewith, or credit any overpayment to Deposit Account No. 15-0030 . 

A duplicate copy of this sheet is enclosed. 



Date: 



22850 

Tel. (703)413-3000 
Fax. (703)413-2220 
(OSMMN 10/00) 



Respectfully Submitted, 

OBLON, SPIVAK, McCLELLAND, 
MAIER & NEUSTADT, P.C. 

Marvin J. Spivak 
Registration No. 24,9 1 3 



124 



ELECTRONIC CATALOG MAINTENANCE SYSTEM FOR ENABLING 
OUT- OF -STANDARD ELECTRONIC CATALOG CHANGES 



5 BACKGROUND OF THE INVENTION 



FIELD OF THE INVENTION 

The present Invention relates to an electronic catalog 
maintenance system for maintaining an electronic catalog 
10 formed according to a prescribed standard such as IS013584. 



DESCRIPTION OF THE BACKGROUND ART 

IS013584 (Parts Library) is the conventionally known 
international standard for implementing the electronic 

15 catalog system for electronically providing product 
information on the Internet. In this IS013584, the 
electronic catalog is formed by dictionary data and 
contents (catalog data) , which are given in a unified data 
structure in order to realize sharing and reuse of the 

20 product information. 

In the dictionary data defined by IS013584, the 
product classification is expressed hierarchically as in an 
example shown in Fig. 27, by relating "product classes" AO, 
BO, Bl and C0-C3 by a single tree structure. Each of the 

25 "product classes" AO, BO, Bl , C0-C3 has "attribute items" 
V0-V6, and the "attribute items" of one "product class" 
(such as VO and VI belonging to BO, for example) are 
inherited to the lower "product classes" (CO and CI). 

Also, in IS013584, a unique ID (identifier) called 

30 "BSU (Basic Semantic Unit) code" is to be assigned to each 
one of the "product classes" and the "attribute items" in 
order to identify it uniquely. Note that the "attribute 
items" includes "Visible" type attribute items which can 
only be referred and "Applicable" type attribute items for 

35 which actual values can be entered. The "Applicable" type 
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attribute items are to be selected from "Visible" type 
attribute items that can be referred (VO of C2, for 
example) . 

While IS013584 provides a framework for the electronic 
5 catalog, the international standardization of actual 
dictionary data is also in progress, and IEC61360 is 
currently striving for the standardization of the upper 
hierarchy part of the dictionary data in the field of 
electric and electronic products, that is, the general part 

10 regarding the "product classes" and the "attribute items". 
As a result, a product catalog producer of each company can 
creates that company's own contents by determining the 
original detailed "product classes" and "attribute items" 
as a lower level development from 1EC61360. 

15 A user of the electronic catalog can retrieve a 

desired product from the contents created in this way by 
tracing the classification hierarchy of the "product 
classes" and narrowing down products that can meet his/her 
needs by referring to attribute values. In recent years, 

20 several systems in compliance with IS013584 have been 
developed in this trend. 

In IS013584 described above, a basic idea of the 
maintenance regarding a dictionary system formed according 
to the definition is described, and in particular, a 

25 mechanism based on Version/Revision updates is described 
for management of the dictionary. 

Figs. 28A and 28B summarize that basic idea. In Fig. 
28A, a way of handling each type is described for addition, 
change, and deletion of associated information of the 

30 attribute item (property). Also, in Fig. 28B, a way of 

handling each type is described for addition, change, and 
deletion of associated information of the product class 
(which will be referred to hereafter as "class"). 

However, according to the agreement shown in Figs. 28A 

35 and 28B, changes of the dictionary are very limited, and in 
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particular, chang-es required in the following cases cannot 
be handled. 

Case 1) Deletion of Visible/Applicable Property 
Case 2) Change of Visible/Applicable Property 
5 Case 3) Change which deletes a Property to be 

inherited, among changes of Super Class 

Case 4) Change of Name scope of Visible Property 
Note however that, In Case 2), the "Version UP of 
Property" event is excluded, and addition of 
10 Visible/Applicable Property can be handled by Version up. 

Note also that, in Case 3), the "Version UP of Super 
Class" event is excluded, and change which does not delete 
a Property to be inherited such as insertion of an 
intermediate class can be handled by Version up, while 
15 change of Preferred Name can be handled by Revision up. 

Now, it is expected that these Case 1) to Case 4) will 
occur frequently in practice as in the case of changing the 
class hierarchy structure. For example, they are expected 
to occur in the case of newly creating a class (FFF) at an 
20 end (EEE) of the tree structure as shown in Fig. 29, the 
case of deleting an end class (HHH) as shown in Fig. 30, 
the case of merging a plurality of product classes (EEE and 
HHH) to one product class (KKK) as shown in Fig. 31, the 
case of moving the product class (HHH or DDD) as shown in 
25 Figs, 32, 33, 34 and 35, and the case of creating or 

deleting an intermediate class (HHH) as shown in Figs. 36 
and 37. 

Consequently, it is practically very important to 
enable handling of such cases as Case 1) to Case 4) by 
30 going beyond the framework of 1S013584. However, the 
following problems are encountered in realizing this. 

First, the BSU code that is once issued and disclosed 
cannot be deleted and must be permanently managed even when 
it becomes unused as it is taken out from the dictionary 
35 system, because there is a possibility of referencing from 
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the leg'acy system, so that there Is a need to be compatible 
with the legacy system. 

Second, one class or attribute can be reg^arded as a 
number of different classes or attributes when the 
5 hierarchy structure Is changed, even If the definition and 
the content of that class or attribute as a single entity 
remain unchanged* This will cause a large number of the new 
issuance of the BSU code and the releasing of the BSU code 
so that the management of codes becomes very difficult. For 
10 this reason, there is a need to provide a function for 
comprehending the new Issuance of the BSU code. 



SUMMARY OF THE INVENTION 

15 

It is therefore an object of the present Invention to 
provide an electronic catalog maintenance system capable of 
improving usefulness and generality of the electronic 
catalog by ensuring the freedom of changes of the 

20 electronic catalog, while making the changed electronic 
catalog data utllizable even in the conventional systems. 

According to one aspect of the present invention there 
is provided an electronic catalog maintenance system, 
comprising: a dictionary database configured to store 

25 dictionary data of an electronic catalog, the dictionary 
data being given in a form of a tree structure formed by 
identifiers for uniquely identifying classes classifying 
products and attributes of the products; an editing unit 
configured to edit the dictionary data stored by the 

30 dictionary database by making changes including standard 
changes defined by a prescribed standard and out-of- 
standard changes not defined by the prescribed standard; a 
change status detection unit configured to detect a status 
of each change made by the editing unit, and to generate an 

35 identifier change data indicating the status of each change 
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made by the editing- unit and updates of identifiers to be 
made in the distrionary data; an identifier update unit 
configured to issue a new identifier of each class or 
attribute created by an out-of -standard change made by the 
5 editing unit, and to retire an old identifier of each class 
or attribute deleted by an out-of -standard change made by 
the editing unit, according: to the identifier change data 
generated by the change status detection unit; and an 
identifier change database configured to store the 

10 identifier chang-e data generated by the change status 
detection unit. 

According to another aspect of the present invention 
there is provided an electronic catalog- maintenance method, 
comprising the steps of: (a) storing dictionary data of an 

15 electronic catalog in a dictionary database, the dictionary 
data being given in a form of a tree structure formed by 
identifiers for uniquely identifying classes classifying 
products and attributes of the products; (b) editing the 
dictionary data stored by the dictionary database by making 

20 changes including standard changes defined by a prescribed 
standard and out-of -standard changes not defined by the 
prescribed standard; (c) detecting a status of each change 
made by the step (b), and generating an identifier change 
data indicating the status of each change made by the step 

25 (b) and updates of identifiers to be made in the dictionary 
data; (d) issuing a new identifier of each class or 
attribute created by an out-of -standard change made by the 
step (b), and releasing an old identifier of each class or 
attribute deleted by an out-of -standard change made by the 

30 step (b) , according to the identifier change data generated 
at the step (c) ; and (e) storing the identifier change data 
generated by the step (c) in an identifier change database. 

According to another aspect of the present invention 
there is provided a computer usable medium having computer 

35 readable program codes embodied therein for causing a 
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computer to function as an electronic catalog maintenance 
system, the computer readable prog-ram codes include: a 
first computer readable program code for causing said 
computer to store dictionary data of an electronic catalog 
5 in a dictionary database, the dictionary data being given 
in a form of a tree structure formed by identifiers for 
uniquely identifying classes classifying products and 
attributes of the products; a second computer readable 
program code for causing said computer to edit the 

10 dictionary data stored by the dictionary database by making 
changes Including standard changes defined by a prescribed 
standard and out-of -standard changes not defined by the 
prescribed standard; a third computer readable program code 
for causing said computer to detect a status of each change 

15 made by the editing unit, and to generate an identifier 
change data indicating the status of each change made by 
the editing unit and updates of identifiers to be made in 
the dictionary data; a fourth computer readable program 
code for causing said computer to issue a new Identifier of 

20 each class or attribute created by an out-of -standard 
change made by the editing unit, and to retire an old 
identifier of each class or attribute deleted by an out-of- 
standard change made by the editing unit, according to the 
identifier change data generated by the third computer 

25 readable program code; and a fifth computer readable 
program code for causing said computer to store the 
identifier change data generated by the third computer 
readable program code in an identifier change database. 

Other features and advantages of the present invention 

30 will become apparent from the following description taken 
in conjunction with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 
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Fig:. 1 is a block diagram showing an overall 
configuration of an electronic catalog maintenance system 
according to one embodiment of the present invention. 

Fig. 2 is a diagram showing an example of class data 
5 in electronic catalog dictionary data used by the 
electronic catalog maintenance system of Fig. 1. 

Fig. 3 is a diagram showing an example of attribute 
data in electronic catalog dictionary data used by the 
electronic catalog maintenance system of Fig. 1. 
10 Fig. 4 is a diagram showing an example of class- 

attribute relationship data in electronic catalog 
dictionary data used by the electronic catalog maintenance 
system of Fig. 1. 

Fig. 5 is a diagram showing an example of class BSU 
15 code change data in BSU code change data used by the 
electronic catalog maintenance system of Fig. 1. 

Fig. 6 is a diagram showing an example of attribute 
BSU code change data in BSU code change data used by the 
electronic catalog maintenance system of Fig. 1. 
20 Fig, 7 is a diagram showing an exemplary model for 

expressing version tree data and revision tree data used by 
the electronic catalog maintenance system of Fig. 1. 

Fig. 8 is a diagram showing an exemplary data 
description of version tree data and revision tree data 
25 used by the electronic catalog maintenance system of Fig. 
1. 

Fig. 9 is a diagram showing an example of dictionary 
system quality data used by the electronic catalog 
maintenance system of Fig, 1, 
30 Fig, 10 is a flow chart for an overall processing of 

the electronic catalog maintenance system of Fig. 1. 

Fig. 11 is a flow chart for a processing by a master 
database management unit at the step S3 of Fig. 10. 

Fig. 12 is a flow chart for a processing by an editing 
35 database management unit at the step S4 of Fig. 10. 
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Fig. 13 is a flow chart for a processing* by a 
dictionary change status detection function at the step S13 
of Fig:, 10. 

Fig. 14 is a diagram showing an example of change type 
5 discrimination rules used by the electronic catalog 
maintenance system of Fig. 1. 

Fig. 15 is a flow chart for a processing by a summary 
generation function with respect to class data at the step 
S16 of Fig. 10. 

10 Fig. 16 Is a flow chart for a processing by a summary 

generation function with respect to attribute data at the 
step S16 of Fig. 10, 

Fig. 17 Is a diagram showing an exemplary manner of 
changing BSU codes due to dictionary data editing at the 
15 step S12 of Fig. 10. 

Fig. 18 is a diagram showing class BSU code change 
data and its summary generated as a result of changes shown 
in Fig. 17. 

Fig. 19 is a diagram showing attribute BSU code change 
20 data and its summary generated as a result of changes shown 
in Fig, 17. 

Fig. 20 is a flow chart for a processing by a 
dictionary system quality check function at the step S17 of 
Fig, 10. 

25 Fig. 21A is a diagram showing an example of quality 

check rules used by the electronic catalog maintenance 
system of Fig, 1, 

Fig. 21B is a diagram showing an example of BSU code 
issuance rules used by the electronic catalog maintenance 
30 system of Fig. 1. 

Fig. 22 is a flow chart for a processing by an editing 
database management unit at the step S18 of Fig. 10. 

Fig. 23 is a flow chart for a processing by a BSU code 
update function with respect to class data at the step S22 
35 of Fig. 10. 
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Fig". 24 Is a flow chart for a processing by a BSD code 
update function with respect to attribute data at the step 
S22 of Fig:. 10, 

Fig'. 25 is a flow chart for a processing by a master 
5 database management unit at the step S23 of Fig. 10, 

Fig. 26 is a diagram showing computer readable 
recording media for recording an electronic catalog 
maintenance program according to the present invention. 

Fig. 27 is a diagram showing an exemplary electronic 
10 catalog data structure according to 1S013584, 

Fig. 28A is a diagram showing Version/Revision update 
rules for property (attribute) as defined by 1S013584. 

Fig. 28B is a diagram showing Version/Revision update 
rules for class (attribute) as defined by IS013584. 
15 Fig. 29 is a diagram showing an exemplary BSU code 

change due to an electronic catalog change for creation of 
end class. 

Fig. 30 is a diagram showing an exemplary BSU code 
change due to an electronic catalog change for deletion of 
20 end class. 

Fig, 31 is a diagram showing an exemplary BSU code 
change due to an electronic catalog change for merging of 
classes . 

Fig. 32 is a diagram showing an exemplary BSU code 
25 change due to an electronic catalog change for moving of a 
class . 

Fig. 33 is a diagram showing an exemplary BSU code 
change due to an electronic catalog change for moving of a 
class . 

30 Fig. 34 is a diagram showing an exemplary BSU code 

change due to an electronic catalog change for moving of a 
class . 

Fig. 35 is a diagram showing an exemplary BSU code 
change due to an electronic catalog change for moving of a 
35 class. 
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Fi^. 36 Is a diagram showing- an exemplary BSU code 

chang'e due to an electronic catalog" change for creation of 
an intermediate class, 

Fig. 37 is a diagram showing an exemplary BSU code 

5 chang-e due to an electronic catalog change for deletion of 
an intermediate class. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

10 

Referring- now to Fig. 1 to Fig. 26, one embodiment of 
the electronic catalog- maintenance system according- to the 
present invention will be described in detail. 

(Overall configuration of the electronic catalog- 
15 maintenance system) 

Fig. 1 shows a schematic configuration of the 
electronic catalog maintenance system according to this 
embodiment . 

As shown in Fig. 1, the electronic catalog maintenance 

20 system of this embodiment comprises a dictionary editor 1, 
a BSU code change management function 2, a dictionary 
chang-e status detection function 5, a dictionary system 
quality check function 6, an editing database management 
unit 7, a master database manag-ement unit 8, an electronic 

25 catalog- dictionary editing database 14, a BSU code chang-e 
management editing: database 16, an electronic catalog- 
dictionary master database 20, and a BSU code change 
management master database 22. 

The dictionary editor 1 newly creates or edits the 

30 electronic catalog dictionary data 10. In this embodiment, 
this dictionary editor 1 can store the newly created or 
edited electronic catalog dictionary data 10 into the 
electronic catalog dictionary editing database 14 or the 
electronic catalog dictionary master database 20, and read 

35 out the electronic catalog dictionary data 10 from the 
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electronic catalog dictionary editing database 14 or the 
electronic catalog- dictionary master database 20 and edit 
them. 

The BSD code change management function 2 has a 
5 summary generation function 3 and a BSU code update 

function 4. The summary generation function 3 generates a 
summary of changes by deleting redundant portion from the 
BSU code change data 9 at a time of storing the electronic 
catalog dictionary data 10. The BSU code update function 4 

10 updates the BSU codes in the electronic cataqlog dictionary 
data 10 according to the generated summary and BSU code 
issuance rules 11. 

The dictionary change status detection function 5 
detects how BSU codes will be affected by the editing of 

15 the electronic catalog dictionary data 10 made by the 

dictionary editor 1 according to change type discrimination 
rules 12, and generates the BSU code change data 9. 

The dictionary system quality check function 6 checks 
a quality of the updated electronic catalog dictionary data 

20 10 according to quality check rules 13, and generates 
dictionary system quality data 26. 

The editing database management unit 7 manages data 
input/output with respect to the electronic catalog 
dictionary editing database 14 and the BSU code change 

25 management editing database 16. 

The master database management unit 8 manages data 
input/output with respect to the electronic catalog 
dictionary master database 20 and the BSU code change 
management master database 22. 

30 The electronic catalog dictionary data 10 updated as a 

result of the editing or the like will be stored into the 
electronic catalog dictionary editing database 14 by the 
editing database management unit 7, as editing electronic 
catalog dictionary data 15. Also, the BSU code change data 

35 9 that became the summary and the dictionary system quality 
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data 26 are stored Into the BSU code change manag-ement 
editing database 16 by the editing database management unit 
7 similarly, as editing BSU code change data IT and editing 
dictionary system quality data 19 respectively. At a time 
5 of storing these data, the editing database management unit 
7 generates and manages Revision Tree data 18 describing 
relationships among these data in order to carry out the 
revision management of the dictionary. 

Among the electronic catalog dictionary data 15 stored 

10 in the electronic catalog dictionary editing database 14, 
data to be used as a disclosure version which have a high 
level of completeness will be sent to the master database 
management unit 8, and managed in the electronic catalog 
dictionary master database 20 as master electronic catalog 

15 dictionary data 21. At the same time, the corresponding 
editing BSU code change data 17 and the corresponding 
editing dictionary system quality data 19 will be also 
stored in the BSU code change management roaster database 22 
as master BSU code change data 23 and master dictionary 

20 system quality data 25 respectively. At a time of storing 
these data, the master database management unit 8 generates 
and manages Version Tree data 24 describing relationships 
among these data in order to carry out the version 
management of the dictionary. 

25 (Configuration of the electronic catalog dictionary 

data) 

Next, the contents of the electronic catalog 
dictionary data 10 or 15 to be stored in the electronic 
catalog dictionary editing database 14 and edited by the 
30 dictionary editor 1 will be described. Fig. 2 to Fig. 4 
show exemplary configurations of the electronic catalog 
dictionary data 10 or 15. 

Fig. 2 shows an example of class data in the 
electronic catalog dictionary data 10 or 15, where one line 
35 Indicates information of one class. In this information, a 
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"CID" which is an ID for identifying the class internally, 
a *'BSU" which describes a BSU code of the class, and a 
"parent class CID'' which describes a CID of a class that is 
a parent on the hierarchy structure of classes will be 
5 automatically assigned by the dictionary editor 1 and the 
BSU code change management function 2 in this embodiment. 
Note that the electronic catalog dictionary data 10 or 15 
in this embodiment contain associated information of the 
class as specified by IS013584 including a "Preferred Name" 

10 which indicates a name of the class, and this will be 

entered by a user. Also, a value of a "data quality level" 
in this electronic catalog dictionary data 10 or 15 will be 
written by the dictionary system quality check function 6. 
Fig. 3 shows an example of attribute data in the 

15 electronic catalog dictionary data 10 or 15, where one line 
indicates information of one attribute. In this 
information, a "PID" which is an ID for identifying the 
attribute internally and a "BSU" which describes a BSU code 
of the attribute will be automatically assigned by the 

20 dictionary editor 1 and the BSU code change management 
function 2 in this embodiment. There is also associated 
information of the attribute as specified by IS013584 
including a "Preferred Name" which indicates a name of the 
attribute, and this will be entered by a user. Also, a 

25 value of the data quality level will be written by the 
dictionary system quality check function 6. 

Fig. 4 shows an example of class-attribute 
relationship data in the electronic catalog dictionary data 
10 or 15, where one line indicates information of one 

30 class-attribute relationship. In this information, a 

"CID_scope" describes a class for which this attribute is 
defined, a "Visible" describes a list of classes that can 
be referred by this attribute, and "Applicable" describes a 
list of classes to which this attribute can be applied. 

35 (Configuration of the BSU code change data) 
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Next, the contents of the BSU code change data 9 or 17 
to be generated by the editing of the electronic catalog 
dictionary data 10 or 15 by the dictionary editor 1 and 
stored in the BSU code change management editing database 
5 16 will be described. Fig. 5 and Fig. 6 show exemplary 
configurations of the BSU code change data 9 or 17. 

Fig. 5 shows an example of BSU code change data for 
classes in the BSU code change data 9 or 17 where one line 
indicates information of one BSU code change event. In this 

10 information, a "Status" indicates an event type which can 
take four values (VUP, RUP , NEW, OOD) . Here, "VUP" and 
"RUP" indicate change events in accordance with the 
Version/Revision management specification of IS013584 as 
shown in Figs, 28A and 28B. Also, "NEW" indicates one for 

15 which there is a need to newly issue a BSU code as a result 
of a change event. Also, "OOD" indicates one for which 
there is a need to retire a BSU code as it is excluded 
from the dictionary system. 

For each "Status", "CID" of the class with respect to 

20 which the change is made. "BSU", and "Refer_to" and 
"Same_as" which indicate relationships of generation 
changes among classes are given. Using these two 
relationships, it is possible to access the registered 
class through the generation change, even in the case of 

25 making access to the dictionary by using a retired BSU code 
which is already excluded from the dictionary system. 

Fig. 6 shows an example of BSU code change data for 
attributes in the BSU code change data 9 or 17, where one 
line indicates information of one BSU code change event. In 

30 this information, a "Status" indicates an event type which 
can take four values (VUP, RUP, NEW, OOD). Here, "VUP" and 
"RUP" indicate change events in accordance with the 
Version/Revision management specification of IS013584 as 
shown in Figs. 28A and 28B. Also, "NEW" indicates one for 

35 which there is a need to newly issue a BSU code as a result 
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of a change event. Also, "OOD" indicates one for which 
there is a need to retire a BSU code as It is excluded 
from the dictionary system. 

For each "Status", "PID" of the attribute with respect 
5 to which the change is made, "BSU", and "Refer__to" and 
"Same_as" which indicate relationships of generation 
changes among attributes are given. Using these two 
relationships, it is possible to access the registered 
attribute through the generation change, even in the case 
10 of making access to the dictionary by using a retired BSU 
code which is already excluded from the dictionary system. 

(Configuration of Version Tree data) 

Next, the Version Tree data to be stored in the BSU 
code change management editing database 16 or the BSU code 
15 change management master database 22 will be described. 

Fig. 7 shows a model for expressing the Version Tree 
data 24 and the Revision Tree data 18 used in Fig, 1 in 
terms of EXPRESS-G, which is an ER model in which a 
rectangle represents an entity and a line represents a 
20 relation. 

In Fig. 7, a "DB_Version" entity represents the master 
electronic catalog dictionary data 21, a "Version_History" 
entity represents the master BSU code change data 23, a 
"DB_Revision" entity represents the editing electronic 

25 catalog dictionary data 10, a "Revlsion_History" entity 
represents the editing BSU code change data 17, and a 
^'DB__quality" entity represents the editing dictionary 
system quality data 19 and the master dictionary system 
quality data 25. 

30 Fig. 8 shows an exemplary data description of the 

Version Tree data 24 and the Revision Tree data 18, which 
is described according to a model shown in Fig. 7, and 
which will be used as information for the version 
management of each data. In Fig. 8, a portion enclosed by 

35 an enclosure 30 represents the Version Tree data 24, and a 
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portion enclosed by an enclosure 31 represents the Revision 
Tree data 18. 

(Conf ig-uratlon of the dictionary system quality data) 
Next, the contents of the dictionary system quality 
5 data 26 to be generated by the dictionary system quality 
check function 6 will be described. 

Fig- 9 shows an example of the dictionary system 
quality data 26, where quality evaluation values are 
described from viewpoints of classes, attributes, and the 
10 entire dictionary itself. These values are calculated by 
the dictionary system quality check function 6 by 
evaluating" the electronic catalog dictionary data 10 and 
the BSU code change data 9 according to the quality check 
rules 13. 

15 (Processing by the electronic catalog maintenance 

system) 

The electronic catalog maintenance system of this 
embodiment in the above described configuration carries out 
the electronic catalog maintenance operation as follows. 

20 Fig. 10 shows a flow chart for an overall processing to be 
carried out by the electronic catalog maintenance system of 
this embodiment. 

As shown in Fig. 10, when the dictionary editor 1 is 
activated (step SI), whether the electronic catalog 

25 dictionary data to be edited is a new one or an existing 
one is Judged (entered) (step S2) . Then, in the case of 
newly creating an electronic catalog dictionary, the 
processing for generating a new dictionary is carried out 
at the steps S3 and S4, whereas in the case of reading 

30 existing data, whether that data is stored in the 

electronic catalog dictionary editing database 14 or the 
electronic catalog dictionary master database 20 is Judged 
(step S5) . In the case of reading from the electronic 
catalog dictionary editing database 14, the processing of 

35 the step Sll is carried out, whereas in the case of reading 
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from the electronic catalog- dictionary master database 20, 
the processing of the steps S6 to SIO is carried out. 

Next, the electronic catalog' dictionary data 10 so 
created or read will be changed by the editing processing 
5 of the step S12. Then, the content of that change is 
checked by the processing of the step S13. Namely, the 
dictionary change status detection function 5 compares the 
editing content made by the dictionary editor 1 with the 
change type discrimination rules 12 to determine the 

10 editing content as one of a Revision UP change, a Version 
UP change and a New BSU change, and generates the check 
result as the BSU code change data 9. 

When it is desired to store the edited electronic 
catalog dictionary data 10 (step S14 YES and step S15 YES), 

15 it is stored into the electronic catalog dictionary editing 
database 14 (step S18) after the summary generation 
processing of the step S16 and the quality check processing 
of the step S17* On the other hand, when it is desired to 
store the electronic catalog dictionary data 10 with a high 

20 level of completeness as the master data (step S19 YES), it 
is stored into the electronic catalog dictionary master 
database 20 (step S23) after the quality of the dictionary 
is confirmed at the steps S20 and S21, and the BSU code is 
Issued and the Version/Revision update is carried out at 

25 the step S22. 

In the following, each processing will be described in 
further detail. Fig, 11 shows a flow chart for a processing 
to be carried out by the master database management unit 8 
in the processing of the step S3 of Fig. 10, that is the 

30 processing for newly creating the electronic catalog 
dictionary data 10. 

As shown in Fig. 11, in the processing of the step S3 
described above, when the master database (name) is entered 
at the step S30, the Version Tree data 24 based on a model 

35 shown in Fig. 7 is created and stored by the steps S31 to 
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S34, and the necessary information is transmitted to the 
editing: database management unit 7 by the step S35. Then, 
an empty electronic catalog dictionary data 21 is created 
and stored by the step S36 and an empty BSU code change 
5 data 23 is created and stored by the step S37. 

Fig. 12 shows a flow chart for the processing of the 
step S4 in Fig, 10, that is a processing to be carried out 
by the editing database management unit 7 in the processing 
for newly creating the electronic catalog dictionary data 
10 10. 

As shown in Fig. 12, the necessary information is 
received from the master database management unit 8 at the 
step S40, and the Revision Tree data 18 is created and 
stored by the steps S41 to S45. Then, an empty electronic 

15 catalog dictionary data 15 is created and stored by the 
step S46 and an empty BSU code change data 17 is created 
and stored by the step S47. At the same time, an empty 
electronic catalog dictionary data 10 is created and stored 
by the step S48 and an empty BSU code change data 9 is 

20 created and stored by the step S49. 

Fig. 13 shows a flow chart for the processing of the 
step S13 in Fig. 10, that is a processing to be carried out 
by the dictionary change status detection function 5 in the 
processing for checking the change content of the edited 

25 electronic catalog dictionary data 10. 

As shown in Fig. 13, the dictionary change event is 
detected at the step SlOO and discriminated according to 
the change type discrimination rules 12 shown in Fig. 14 at 
the step SlOl. Then, depending on whether the event type is 

30 that related to the class or that related to the attribute 
(step S102), the subsequent steps S103 to SllO are carried 
out when the event type is that related to the class, 
whereas the subsequent steps Sill to S118 are carried out 
when the event type is that related to the attribute, so as 

35 to generate the BSU code change data 9. 
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Fig-. 14 shows an example of the change type 
discrimination rules 12 describing the rules to be used in 
the processing of Fig. 13. 

As shown In Fig. 14, the change type discrimination 
5 rules 12 are largely divided into rules for the product 
class change and the rules for the attribute change, and 
each rule describes a condition for judging whether each 
change is Revision UP, Version UP or New BSU, and a 
processing method suitable for each type. Note that these 

10 judgement condition and processing method are described in 
the IF-THEN format in this embodiment, but they may be 
described in any other format. 

Then, as a result of the judgement according to the 
change type discrimination rules 12, if the change of the 

15 BSU code change data 9 is related to the class, whether 
that change is Revision UP, Version UP, or New BSU is 
checked, whether there is a class to be retired or not is 
checked, and the BSU code change data 9 is changed 
according to the rule to be applied. If the change of the 

20 BSU code change data 9 is related to the attribute, the 
rule to be applied is checked similarly. 

Fig. 15 shows a flow chart for a processing to be 
carried out by the summary generation function 3 with 
respect to the class data in the processing of the step S16 

25 of Fig, 10. Here, the processing is branched according to 
"Status'* of each event described in the BSU code change 
data 9 and the status of BSU code issuance. By this 
processing, the redundant operation can be removed from the 
editing operation, and only significant changes including 

30 the BSU code change can be extracted. 

Among symbols used in Fig. 15, "Status" indicates the 
"Status" attribute of the class BSU code change data, "BSU" 
indicates the "BSU" attribute of the class BSU code change 
data, "CID" Indicates the "CID" attribute of the class BSU 

35 code change data, "Same_as" Indicates "Same_as" attribute 
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of the class BSU code chang-e data, "Refer_to" indicates the 
**Refer__to" attribute of the class BSU code change data, and 
"A. Status" indicates the "Status" attribute value of the 
class BSU code change data A. 
5 Also, among alphabets attached to these symbols, "R" 

indicates the tail end data of the class BSU code change 
data, "X" indicates the class BSU code change data whose 
CID value is equal to "R.Refer_to" value. "S" indicates the 
class BSU code change data whose CID value is that of the 

10 parent (upper level) class of "R.CID" value and whose 

"Status" value is "NEW", "Y" indicates the class BSU code 
change data whose "Status" value is "NEW" and whose CID 
value is equal to "R.CID" value, "Z" indicates the class 
BSU code change data whose "Status" value is "OOD" and 

15 whose "Refer_to" value is equal to "Y,CID" value, "T" 
indicates the class BSU code change data whose "Status" 
value is "VUP" or "RUP" and whose CID value is equal to 
"R.CID" value, and "K" indicates the class BSU code change 
data whose "Status" value is equal to "R. Status" value and 

20 whose CID value is equal to "R.CID" value. 

First, the BSU code change data related to the class 
is read (step S201) , the tail end data R is detected (step 
S202) , and the processing is terminated when the data R 
does not exist (step S203 NO), or otherwise the processing 

25 from the step S204 on is carried out. 

In the processing from the step S204 on, whether 
"R, Status" value is "OOD" or not is judged (step S204) , and 
if "R. Status" is "OOD", whether "R.BSU" value is "NULL" or 
not is Judged (step S205). 

30 When it is judged that "R.BSU" value is "NULL" at the 

step S205, Y for which "Y. Status" value is "NEW" and 
"Y.CID" value is equal to "R.CID" value is obtained, Z for 
which "Z. Status" value is "OOD" and "Z.Refer_to" value is 
equal to "Y.CID" value is obtained, and X for which 

35 "X. Status" value is "NEW" and "X.CID" value is equal to 
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"R.Ref er__to" value is obtained (steps S209, S210, S211) . 
Then, whether such X and Z exist or not is Judg*ed (steps 
S212, S213, S215). Then, depending on a combination of the 
existing X and Z, "NULL" is substituted into "Z . Ref er__to" 
5 (step S214), "R.CID" is replaced by "Z.CID" and "X.CID" is 
substituted into "X. Ref er__to" (steps S216, S217) , "R.CID" 
is deleted (step S218), every T for which "T. Status" is 
"VUP" or "RUP" and "T.CID" value is equal to "R.CID" value 
is obtained (step S219) , and R, Y and T are deleted (step 
10 S220). 

When it is judged that "R.BSU" value is not "NULL" at 
the step S205, X for which "X.CID" value is equal to 
"R.Refer_to" value is obtained (step S206) , and if such X 
does not exist (step S207 NO), the parent class S of 

15 "R.CID" is obtained and "S.CID" is set to "R,Refer_to" 
(step S208) . 

On the other hand, when it is judged that the 
"R. Status" value is not "OOD" at the step S204, whether 
"R. Status" value is "NEW" or not is judged (step S221), and 

20 if it is "NEW", every K for which "K. Status" value is equal 
to "R. Status" value and "K.CID" value is equal to "R.CID" 
value is obtained (step S222) and K is deleted (step S223) . 
Then, whether "R.BSU" is "NULL" or not is Judged (step 
S224), and if so R is deleted (step S225). 

25 After R is obtained in this way, the data Immediately 

before R is substituted into this obtained data R (step 
S226), and the next processing is started by the loop 
processing. 

Fig, 16 shows a flow chart for a processing to be 
30 carried out by the summary generation function 3 with 

respect to the attribute in the processing of the step S16 
of Fig. 10. Here, the processing is branched according to 
"Status" of each event described in the BSU code change 
data 9 and the status of BSU code issuance, similarly as 
35 Fig, 15* By this processing, the redundant operation such 
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as a change related to the class that was once newly 
created but then deleted on the second thoug-ht, for 
example, can be removed from the editing operation, and 
only significant changes Including the BSU code change can 
5 be extracted. 

Among symbols used in Fig. 16, '*PID" indicates the 
"PID" attribute of the attribute BSU code change data, and 
"A. FID" indicates the "FID'* attribute value of the class 
BSU code change data A. Also, among alphabets attached to 

10 these symbols, "R'* indicates the tall end data of the 

attribute BSU code change data, "X" indicates the attribute 
BSU code change data whose "Status*' value is "NEW" and 
whose FID value is equal to "R,Refer_to" value, "Y" 
indicates the attribute BSU code change data whose "Status" 

15 value Is "NEW" and whose FID value is equal to "R.PID" 
value, "Z" indicates the attribute BSU code change data 
whose "Status" value is "OOD" and whose "Refer_to" value is 
equal to "Y.FID" value, "T" indicates the attribute BSU 
code change data whose "Status" value is "VUP" or "RUP" and 

20 whose FID value is equal to "R.PID" value, and "K" 

indicates the attribute BSU code change data whose "Status" 
value is equal to "R. Status" value and whose FID value is 
equal to "R.PID" value. 

First, the BSU code change data related to the 

25 attribute is read (step S301) , the tail end data R is 

detected (step S302), and the processing is terminated when 
the data R does not exist (step S303 NO), or otherwise the 
processing from the step S304 on is carried out. 

In the processing from the step S304 on, whether 

30 "R. Status" value is "GOD" or not is judged (step S304) , and 
if "R. Status" is "GOD", whether "R.BSU" value is "NULL" or 
not is judged (step S305) . 

When it is judged that "R.BSU" value is "NULL" at the 
step S305, Y for which "Y. Status" value is "NEW" and 

35 "Y.FID" value is equal to "R.PID" value is obtained, Z for 
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which "Z. Status" value is "OOD" and "Z,Refer_to" value is 
equal to "Y.PID" value is obtained, and X for which 
"X. Status" value is "NEW" and "X.PID" value is equal to 
"R.Refer_to" value is obtained (steps S306. S307, S308). 
5 Then, whether such X and Z exist or not is judg-ed (steps 
S309, S310, S312) . Then, depending on a combination of the 
existing X and Z, "NULL" is substituted into "Z . Ref er__to" 
(step S311), "R.PID" is replaced by "Z.PID" and "X.PID" is 
substituted into "X.Refer_to" (steps S313, S314) , "R.PID" 
10 is deleted (step S315) , every T for which "T. Status" is 

"VUP" or "RUP" and "T.PID" value is equal to "R.PID" value 
is obtained (step S316) , and R, Y and T are deleted (step 
S31T) . 

On the other hand, when it is judged that the 

15 "R. Status" value is not "OOD" at the step S304, whether 

"R. Status" value is "NEW" or not is judged (step S318) , and 
if it is "NEW", every K for which "K. Status" value is equal 
to "R. Status" value and "K.PID" value is equal to "R.PID" 
value is obtained (step S319) and K is deleted (step S320). 

20 Then, whether "R.BSU" is "NULL" or not is Judged (step 
S321), and if so R is deleted (step S322) . 

After R is obtained in this way, the data immediately 
before R is substituted into this obtained data R (step 
S323) , and the next processing is started by the loop 

25 processing. When it is judged that "R.BSU" value is not 
"NULL" at the step S305, and when it is judged that 
"R. Status" value is "NEW" at the step S318, this step S323 
is carried out immediately. 

(Change of the BSU code) 

30 In the following, the concrete examples of the 

electronic catalog maintenance by the electronic catalog 
maintenance system described above will be described. Fig. 
17 shows an exemplary BSU code change by the dictionary 
data editing processing of the step S12 of Fig. 109. 

35 First, as shown in a part (a) of Fig. 17, suppose that 
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Bl is deleted and the note of CO is changed. As a result, 
as shown in a part (b) of Fig-. 17, C2 and C3 located below 
the deleted Bl are directly connected below AO as C4 and 
C5, and Revision UP of CO for which the note is changed is 
5 carried out. At this point, C2 and C3 located below the 
deleted Bl are set in retired states, and V4, V5 and V6 
that are belonging only to Bl, C2 and C3 are also set in 
retired states. 

Next, when C4 and C5 are merged, as shown in a part 

10 (c) of Fig. 17, a new C6 is created instead of the merged 
C4 and C5 , and C4 and C5 are set in retired states. At this 
point, V7, V8, V9 and VIO that are belonging only to the 
merged C4 and 05 are also set in retired states, and Vll, 
V12, V13 and V14 are newly added instead of them. 

15 (Summary generation) 

In the case of making such a change in the electronic 
catalog dictionary data, the BSD code change data for the 
class and the attribute created by the change and their 
summary will be generated as follows. 

20 A part (a) of Fig. 18 shows the class BSU code change 

data created by the dictionary change status detection 
function 5 when the operations of Fig. 17 are carried out. 
Then, by carrying out the processing of Fig. 15 described 
above with respect to these data, these data are updated as 

25 shown in parts (b) to (e) of Fig. 18. In this way, it can 
be seen that only the significant change operations for the 
class are extracted. 

Fig. 19 shows the attribute BSU code change data 
created by the change of Fig. 17 and a manner of generating 

30 their summary, 

A part (a) of Fig. 19 shows the attribute BSU code 
change data created by the dictionary change status 
detection function 5 when the operations of Fig. 17 are 
carried out. Then, by carrying out the processing of Fig. 

35 16 described above with respect to these data, these data 
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are updated as shown in parts (b) to (i) of Fl^. 19. In 
this way, it can be seen that only the significant change 
operations for the attribute are extracted. 
(Quality check of the dictionary) 
5 Next, the operation of the dictionary quality check 

function, which is one of the functions of the electronic 
catalog maintenance system of this embodiment, will be 
described. Fig. 20 shows a flow chart for a processing of 
the dictionary system quality check function 6 to generate 

10 the dictionary system quality data 26 in the processing of 
the step S17 of Fig. 10. 

First, by the steps S401 to S407 of Fig. 20, the class 
BSU code change data that became the summary are read, a 
top data R is obtained, the quality of individual class is 

15 evaluated according to the quality check rules 13, and its 
value is written into the "data quality level" field of the 
class data. 

Here, as the quality check rules 13, tables formed by 
the evaluation conditions and the evaluation functions as 

20 shown in Fig. 21A can be used, for example. As shown in 

Fig. 21A, the quality check rules 13 can be formed from the 
evaluation of Individual class, the evaluation of 
individual attribute, the evaluation regarding the class 
hierarchy structure, the evaluation regarding the attribute 

25 overlaps, and the evaluation regarding the entire 

dictionary, for example. Note that the quality evaluation 
is made by calculating the quality level by using such 
quality check rules 13 in this embodiment, but it is also 
possible to account for the importance of associated items, 

30 and it is also possible to set evaluation functions based 
on different evaluation axes. 

Then, at the steps S408 and S409, the overall quality 
of the class data such as the consistency of the hierarchy 
structure for example is evaluated according to the quality 

35 check rules 13, and added to the dictionary system quality 
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data 26. In addition, at the steps S410 to S416 , the 
quality of individual attribute is evaluated according to 
the quality check rules 13 and its value is written into 
the "data quality level" field of the attribute data. 
5 Next, at the steps S417 and S418, the overall quality 

of the attribute data such as the overlapping" existence of 
Identical definitions for example is evaluated according to 
the quality check rules 13, and added to the dictionary 
system quality data 26. Then, at the step S419, the 

10 dictionary system quality data 26 are evaluated according 
to the quality check rules 13, and the quality level of the 
entire electronic catalog dictionary is calculated and 
added to the dictionary system quality data 26. 

(Processing by the editing database management unit 7) 

15 The data produced by each processing described above 

are stored by the editing database management unit 7, Fig. 
22 shows a flow chart for a processing of the editing 
database management unit 7 to store data in the processing 
of the step S18 of Fig. 10. 

20 As shown in Fig. 22, at the steps S501 to S509, the 

DB_Revision entity and the Revision_History entity for 
describing relationships between the BSD code change data 9 
and the electronic catalog dictionary data 10 that are 
desired to be stored in order to carry out the revision 

25 management of the dictionary are generated, and stored into 
the Revision Tree data 18. 

Next, at the step S510 to S513, the quality 
information of the dictionary is obtained from the 
dictionary system quality data 26, and the DB_quality 

30 entity is generated and stored in the Revision Tree data 18 
similarly. Then, at the step S514, the BSU code change data 
9 created by the summary generation function 3 are stored 
into the BSU code change management editing database 16 as 
the editing BSU code change data 17. Finally, at the step 

35 S515, the electronic catalog dictionary data 10 is stored 
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into the electronic catalog dictionary editing database 14 
as the editing electronic catalog" dictionary data 15. 
(Processing of BSU codes) 

Next, the BSU code change management processing by the 
5 BSU code update function 4 will be described. Fig* 23 shows 
a flow chart for a processing by the BSU code update 
function 4 to update the class data in the processing of 
the step S22 of Fig, 10, and Fig. 24 shows a flow chart for 
a processing by the BSU code update function 4 to update 
10 the attribute data in the processing of the step S22 of 
Fig. 10. 

In the case of the processing for updating the class 
data, as shown in Fig, 23, the processing is carried out 
according to the "Status" value of the BSU code change data 

15 9 read by the step S601. 

Namely, when It is judged that "Status" is "VUP" at 
the step S603, the Version UP is carried out at the steps 
S604 to S608. On the other hand, when it is Judged that 
"Status" is not "VUP" at the step S603 and it is judged 

20 that "Status" is "RUP" at the step S609, the Revision UP is 
carried out at the steps S610 to S614. Else, when it is 
judged that "Status" is not "VUP" at the step S603 and it 
is judged that "Status" is not "RUP" at the step S609, 
whether "Status" is "NEW" or not is judged (step S615) , and 

25 if "Status" is "NEW", the steps S616 to S618 are carried 

out according to the BSU code issuance rules 11 as shown in 
Fig. 21B, such that the new BSU code is issued and written 
into the BSU field of the class data. 

Also, in the case of the processing for updating the 

30 attribute data, as shown in Fig. 24, the processing is 

carried out according to the "Status" value of the BSU code 
change data 9 read by the step S701. 

Namely, when it is Judged that "Status" is "VUP" at 
the step S703, the Version UP is carried out at the steps 

35 S704 and S705. On the other hand, when it is judged that 
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"Status" Is not "VUP" at the step S703 and it is Judged 
that "Status" is "RUP" at the step S706, the Revision UP is 
carried out at the steps S707 and S708 . Else, when it is 
Judged that "Status" is not "VUP" at the step 8703 and it 
5 is judged that "Status" is not "RUP" at the step S706, 

whether "Status" is "NEW" or not is Judged (step S709) , and 
if "Status" is "NEW", the steps S710 to S712 are carried 
out according to the BSU code issuance rules 11 as shown in 
Fig. 21B, such that the new BSU code is issued and written 

10 into the BSU field of the attribute data. 

(Processing by the master database management unit 8) 
The electronic catalog dictionary data with a high 
level of completeness are stored into the electronic 
catalog dictionary master database 20 as the master 

15 electronic catalog dictionary data 21, Fig. 25 shows a flow 
chart for a processing of the master database management 
unit 8 to store data in the processing of the step S23 of 
Fig. 10, 

As shown in Fig. 25, at the steps S801 to S806, the 

20 DB_Version entity and the Version_Hlstory entity for 

describing relationships between the BSU code change data 9 
and the electronic catalog dictionary data 10 that are 
desired to be stored in order to carry out the version 
management of the dictionary are generated, and stored into 

25 the Version Tree data 24. 

Next, at the step S807 to S810 , the quality 
information of the dictionary is obtained from the 
dictionary system quality data 26, and the DB__quality 
entity is generated and stored in the Version Tree data 24 

30 similarly. Then, at the step S811, the BSU code change data 
9 created by the summary generation function 3 are stored 
into the BSU code change management master database 22 as 
the master BSU code change data 23. Finally, at the step 
S812, the electronic catalog dictionary data 10 is stored 

35 into the electronic catalog dictionary master database 20 
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as the master electronic catalog dictionary data 21. 
(Electronic catalog" maintenance program) 
Note that the electronic catalog- maintenance system 
described above can be realized by producing an electronic 
5 catalog maintenance program described in a prescribed 
programming language and installing this maintenance 
program into a general purpose computer such as PC, for 
example . 

Namely, an electronic catalog maintenance software can 

10 be formed by a program for detecting the change status of 
the electronic catalog dictionary data 10 due to the 
editing by the dictionary editor 1 or the like and 
generating the BSU code change data 9 when the change that 
is out of the standard such as IS013584 is made, and a 

15 program for recording the changed electronic catalog 
dictionary data 10 and the BSU code change data 9, 

Note that in this electronic catalog maintenance 
software, it is preferable to include a program for 
generating the summary by simplifying the BSU code change 

20 data 9 by deleting the redundant portion from the change 
history of the BSU code change data 9 as described above. 

This electronic catalog maintenance software may also 
Include a program for setting the BSU codes used before the 
change in retired states when the change status is out of 

25 the standard such as 1S013584 and newly issuing 

corresponding codes to the catalog data or the dictionary 
data relevant to the out-of -standard change, and a program 
for generating and storing the BSU code change data 9 that 
records the correspondence between the retired BSU codes 

30 and the newly issued BSU codes. 

This electronic catalog maintenance software may also 
include a program for evaluating the quality of the 
electronic catalog dictionary system and each element 
constituting the changed electronic catalog dictionary data 

35 10 according to the quality check rules 13, generating the 
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dictionary system quality data 26, and storing the 
dictionary system quality data 26 into the BSU code chang-e 
management editing database 16. 

The electronic catalog maintenance software so 
5 produced can be recorded on recording media 116-119 that 
are readable by a general purpose computer 115 as shown in 
Fig. 26. More specifically, as shown in Fig. 26, this 
electronic catalog maintenance software can be recorded on 
computer readable recording media such as a magnetic 

10 recording medium like a floppy disk 116 or a cassette tape 
119, an optical disk like a CD-ROM 117, and a RAM card 118. 

Then, by using such computer readable recording media 
that record this electronic catalog maintenance software, 
it is possible to easily realize storing, carrying, and 

15 installing of a useful program that has an effect of 

enabling the efficient electronic catalog change management 
and ensuring generality of the electronic catalog by 
carrying out the comprehensive version management for the 
electronic catalog dictionary data relevant to the change 

20 operation. 

As described, according to the electronic catalog 
maintenance system of the present invention, it becomes 
possible to enable the efficient electronic catalog change 
management and ensure generality of the electronic catalog 

25 by carrying out the comprehensive version management for 
the electronic catalog dictionary data relevant to the 
change operation such that the electronic catalog can be 
utilized without requiring a major modification to the 
existing systems. 

30 Here, the prescribed electronic catalog standard can 

be any international standard such as IS013584 (Parts 
Library) and IEC61360, for example. Also, the product 
classification information can be given by "product class 
(class)" or "attribute item (property)", for example. Also, 

35 the identifier can be given by BSU code, for example. 
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Also, the out-of -standard changes include addition or 
deletion of an intermediate hierarchy, issuance of new 
Identifier, and a change of the tree structure that causes 
an occurrence of an identifier in a retired state. This 
5 change status can be detected according to Version/Revision 
updates, presence or absence of a new identifier (ID), and 
presence or absence of an identifier (ID) in a retired 
state, for example. 

Thus, according to the present invention, it is 
10 possible to make the electronic catalog change management 
easier by comparing the electronic catalog before and after 
the change by utilizing the history information, and it is 
possible to improve degrees of freedom in the electronic 
catalog change operations by enabling the out-of -standard 
15 changes. 

Also, according to the present invention, it is 
possible to make the change processing management easier by 
deleting unnecessary change processing (of the case where 
there is no change eventually or the case where there is 

20 only a minor change) such as those occurring in the case of 
the editing in which the changes are made repeatedly by 
trial and error, for example, from the history information. 

Also, according to the present invention, it is 
possible to make access to the contents relevant to the 

25 out-of -standard change from a newly issued identifier, so 
that this system can be used in the legacy system and it is 
possible to ensure usefulness and generality of the 
electronic catalog. 

Also, according to the present invention, it is 

30 possible to realize the change status management in 

accordance with the international standard such as IS013584 
(Parts Library) and IEC61360, for example, so that it is 
possible to improve generality of the electronic catalog. 
Also, according to the present invention, it is 

35 possible to distinguish a minor change at a time of the 
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change operation and a formal change at a time of 
disclosure as a formal version up by selecting- the storage 
unit according to the level of completeness of the 
electronic catalog, so that it is possible to provide the 
5 high quality dictionary. 

Also according to the present invention, it is 
possible to improve the quality of the electronic catalog 
by evaluating the quality of the electronic catalog 
dictionary system and each element constituting the changed 

10 electronic catalog by using the dictionary system quality 
check function. 

It is also to be noted that, besides those already 
mentioned above, many modifications and variations of the 
above embodiments may be made without departing from the 

15 novel and advantageous features of the present invention. 
Accordingly, all such modifications and variations are 
intended to be included within the scope of the appended 
claims . 



25 



30 



35 



-32- 



WHAT IS CLAIMED IS: 



1. An electronic catalog* maintenance system, comprising:: 
a dictionary database configured to store dictionary 
5 data of an electronic catalog, the dictionary data being 

given in a form of a tree structure formed by identifiers 

for uniquely identifying classes classifying products and 

attributes of the products; 

an editing unit configured to edit the dictionary data 
10 stored by the dictionary database by making chang*es 

including standard changes defined by a prescribed standard 

and out-of -standard changes not defined by the prescribed 

standard ; 

a change status detection unit configured to detect a 
15 status of each change made by the editing unit, and to 

generate an identifier change data Indicating the status of 
each change made by the editing unit and updates of 
identifiers to be made in the distrionary data; 

an Identifier update unit configured to issue a new 
20 identifier of each class or attribute created by an out-of- 
standard change made by the editing unit, and to retire an 
old Identifier of each class or attribute deleted by an 
out-of -standard change made by the editing unit, according 
to the identifier change data generated by the change 
25 status detection unit; and 

an identifier change database configured to store the 
identifier change data generated by the change status 
detection unit, 

30 2. The system of claim 1, wherein the change status 

detection unit generates the identifier change data that 
indicates the updates of identifiers to be made such that 
both new identifiers and old identifiers can be used in 
accessing the classes and the attributes after updating by 

35 the Identifier update unit, by referring to the identifier 
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chang'e data stored in the identifier chang*e database. 

3. The system of claim 1, wherein the editing- unit makes 
the standard changes in forms of version/revision updates 

5 defined by IS013584 standard, and the out-of -standard 
changes not defined by IS013584. 

4. The system of claim 1, wherein the change status 
detection unit detects the status of each change made by 

10 the editing unit according' to occurrences of 

version/revision updates, issuance of the new identifier, 
and retirement of the old identifier. 

5. The system of claim 1, further comprising: 

15 a summary generation unit configured to simplify the 

identifier change data by deleting any redundant portion 
from the identifier change data generated by the change 
status detection unit; 

wherein the identifier change database stores the 

20 identifier change data as simplified by the summary 
generation unit. 

6. The system of claim 1, further comprising: 

a quality check unit configured to generate a 
25 dictionary system quality data by evaluating qualities of 
the dictionary data as a whole and each element 
constituting the dictionary data according to prescribed 
quality check rules, after the dictionary data are edited 
by the editing unit; 
30 wherein the identifier change database also stores the 

dictionary system quality data generated by the quality 
check unit. 

7. The system of claim 1, wherein the dictionary database 
35 includes; 
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an editing' dictionary database for storing- a version 
of the dictionary data for which editing operations are in 
progress; and 

a master dictionary database for storing a version of 
5 the dictionary data for which the editing operations are 
completed . 

8, The system of claim 1, wherein the identifier change 
database includes : 

10 an editing identifier change database for storing the 

identifier change data corresponding to a version of the 
dictionary data for which editing operations are in 
progress; and 

a master identifier change database for storing" the 

15 identifier change data corresponding to a version of the 
dictionary data for which the editing operations are 
completed . 

9, An electronic catalog maintenance method, comprising 
20 the steps of: 

(a) storing dictionary data of an electronic catalog in a 
dictionary database, the dictionary data being given in a 
form of a tree structure formed by identifiers for uniquely 
identifying classes classifying products and attributes of 

25 the products; 

(b) editing the dictionary data stored by the dictionary 
database by making changes including standard changes 
defined by a prescribed standard and out-of -standard 
changes not defined by the prescribed standard; 

30 (c) detecting a status of each change made by the step 
(b), and generating an identifier change data indicating 
the status of each change made by the step (b) and updates 
of identifiers to be made in the dictionary data; 
(d) issuing a new identifier of each class or attribute 

35 created by an out-of -standard change made by the step (b) , 



-35- 



and releasing: an old identifier of each class or attribute 
deleted by an out-of -standard change made by the step (b) , 
according to the identifier change data generated at the 
step (c) ; and 

(e) storing the identifier change data generated by the 
step (c) in an identifier change database. 

10. The method of claim 9, wherein the step (c) generates 
the identifier change data that indicates the updates of 
identifiers to be made such that both new identifiers and 
old identifiers can be used in accessing the classes and 
the attributes after updating by the step (d), by referring 
to the identifier change data stored in the identifier 
change database, 

11. The method of claim 9, wherein the step (b) makes the 
standard changes in forms of version/revision updates 
defined by IS013584 standard, and the out-of -standard 
changes not defined by IS013584. 

12. The method of claim 9, wherein the step (c) detects 
the status of each change made by the step (b) according to 
occurrences of version/revision updates, issuance of the 
new identifier, and retirement of the old identifier. 

13. The method of claim 9, further comprising the step of: 

(f ) simplifying the identifier change data by deleting any 
redundant portion from the identifier change data generated 
by the step (c) ; 

wherein the step (e) stores the identifier change data 
as simplified by the step (f) into the identifier change 
database . 

14. The method of claim 9, further comprising the step of: 

(g) generating a dictionary system quality data by 
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evaluating qualities of the dictionary data as a whole and 
each element constituting: the dictionary data according: to 
prescribed quality check rules, after the dictionary data 
are edited by the step (b) ; 

wherein the step (e) also stores the dictionary system 
quality data generated by the step (g) in the Identifier 
change database. 

15. The method of claim 9, wherein the step (a) stores a 
version of the dictionary data for which editing operations 
are in progress, into an editing dictionary database of the 
dictionary database; and 

the method further comprises the step of storing a 
version of the dictionary data for which the editing 
operations are completed, into a master dictionary database 
of the dictionary database. 

16. The method of claim 9, wherein the step (e) stores the 
identifier change data corresponding to a version of the 
dictionary data for which editing operations are in 
progress, into an editing identifier change database of the 
identifier change database; and 

the method further comprises the step of storing the 
identifier change data corresponding to a version of the 
dictionary data for which the editing operations are 
completed, into a master identifier change database of the 
Identifier change database. 

17. A computer usable medium having computer readable 
program codes embodied therein for causing a computer to 
function as an electronic catalog maintenance system, the 
computer readable program codes Include: 

a first computer readable program code for causing 
said computer to store dictionary data of an electronic 
catalog in a dictionary database, the dictionary data being 
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given in a form of a tree structure formed by Identifiers 
for uniquely identifying classes classifying* products and 
attributes of the products; 

a second computer readable program code for causing 
5 said computer to edit the dictionary data stored by the 
dictionary database by making changes including standard 
changes defined by a prescribed standard and out-of- 
standard changes not defined by the prescribed standard; 
a third computer readable program code for causing 

10 said computer to detect a status of each change made by the 
editing unit, and to generate an identifier change data 
indicating the status of each change made by the editing 
unit and updates of identifiers to be made in the 
dictionary data; 

15 a fourth computer readable program code for causing 

said computer to issue a new identifier of each class or 
attribute created by an out-of -standard change made by the 
editing unit, and to retire an old identifier of each class 
or attribute deleted by an out-of-standard change made by 

20 the editing unit, according to the identifier change data 
generated by the third computer readable program code; and 

a fifth computer readable program code for causing 
said computer to store the identifier change data generated 
by the third computer readable program code in an 

25 identifier change database. 

18. The medium of claim 17, wherein the third computer 
readable program code generates the identifier change data 
that indicates the updates of identifiers to be made such 
30 that both new identifiers and old identifiers can be used 
in accessing the classes and the attributes after updating 
by the fourth computer readable program code, by referring 
to the identifier change data stored in the identifier 
change database. 

35 
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19. The medium of claim 17, wherein the second computer 
readable program code makes the standard changes in forms 
of version/revision updates defined by IS013584 standard, 
and the out-of -standard changes not defined by IS013584. 

5 

20. The medium of claim 17, wherein the third computer 
readable program code detects the status of each change 
made by the second computer readable program code according 
to occurrences of version/revision updates, issuance of the 

10 new identifier, and retirement of the old identifier . 

21. The medium of claim 17, further comprising: 

a sixth computer readable program code for causing 
said computer to simplify the identifier change data by 
15 deleting any redundant portion from the identifier change 
data generated by the third computer readable program code; 

wherein the fifth computer readable program code 
stores the identifier change data as simplified by the 
sixth computer readable program code in the identifier 
20 change database. 

22. The medium of claim 17, further comprising: 

a seventh computer readable program code for causing 
said computer to generate a dictionary system quality data 
25 by evaluating qualities of the dictionary data as a whole 
and each element constituting the dictionary data according 
to prescribed quality check rules, after the dictionary 
data are edited by the second computer readable program 
code ; 

30 wherein the fifth computer readable program code also 

stores the dictionary system quality data generated by the 
seventh computer readable program code in the identifier 
change database . 

35 23. The medium of claim 17, wherein the first computer 
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readable program code stores a version of the dictionary 
data for which editing" operations are in prog-ress, into an 
editing dictionary database of the dictionary database; and 
the computer readable program codes further includes 
5 an eighth computer readable program code for causing said 
computer to store a version of the dictionary data for 
which the editing operations are completed, into a master 
dictionary database of the dictionary database, 

10 24. The medium of claim 17, wherein the first computer 
readable prog-ram code stores the Identifier change data 
corresponding" to a version of the dictionary data for which 
editing operations are in prog-ress, into an editing: 
identifier change database of the identifier change 

15 database; and 

the computer readable program codes further includes 
an eighth computer readable program code for causing said 
computer to store the identifier change data corresponding 
to a version of the dictionary data for which the editing 

20 operations are completed, into a master identifier change 
database of the identifier change database. 



25 



30 



35 



-40" 



ABSTRACT OF THE DISCLOSURE 



In an electronic catalog maintenance system using* the 
dictionary data given in a form of a tree structure formed 
5 by identifiers for uniquely identifying: classes classifying 
products and attributes of the products, the dictionary 
data are edited by making changes including standard 
changes defined by a prescribed standard and out-of- 
standard changes not defined by the prescribed standard, 

10 and an identifier change data indicating the status of each 
change made by the editing and updates of identifiers to be 
made in the dictionary data is generated. Then, a new 
identifier of each class or attribute created by an out-of~ 
standard change is issued and an old identifier of each 

15 class or attribute deleted by an out-of -standard change is 
retired according to the identifier change data, while 
storing the identifier change data in an identifier change 
database . 
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FIG. 21A 

A 



RULE 1 : 


IF(E=PRODUCT CLASS) AND (INDIVIDUAL CHECK) 
THFNrF. OUALTTY LEVEL=EVALUATION FUNCTION Fl (E)) 


RULE 2 : 


IF (E=ATTRIBUTE CLASS) AND (INDIVIDUAL CHECK) 
THEN(E.QUALrrY LEVEL=EVALUATION FUNCTION F2(E)) 


RULE 3 : 


IF(E=PRODUCT CLASS) AND (SYSTEM CHECK) 

THEN(SYSTEM QUALITY LEVEL Ll=EVALUATION FUNCTION F3 (E)) 


RULE 4 : 


IF (E=ATTRIBUTE CLASS) AND (SYSTEM CHECK) 

THEN(SYSTEM QUALTTY LEVEL L1=EVALUATI0N FUNCTION F4(E)) 


RULE 5: 


IF(E=DICTIONARY) ^ 
TF[EN(SYSTEM QUALTTY LEVEL Ll=EVALUATION FUNCTION F5(E)) 




EVALUATION 
FUNCTION 1: 


IF((Y=#OF ATTRIBUTES DESCRIBED IN X/# OF ATTRIBUTES 
OF X)>0.9)THEN QUALITY LEVEL="A" 


ELSE IF (0.9^Y>0.6) THEN QUALITY LEVEL="B" 


ELSE IF (0.6^Y>0.4) THEN QUALITY LEVEL="C" 


ELSE IF (0.4^Y) THEN QUALITY LEVEL="D" 


EVALUATION 
FUNCTION 2: 


IF((Y=#OF ATTRIBUTES DESCRIBED IN X/# OF ATTRIBUTES 
OF X)>0.95)THEN QUALITY LEVEL="A" 


ELSE IF (0.95 ^Y>0.8) THEN QUALITY LEVEL="B" 


ELSE IF(0.8^Y>0.6)THEN QUALITY LEVEL="C" 


ELSE IF m.6^Y) THEN QUALITY LEVEL="D" 


EVALUATION 
FUNCTION 3: 


EF (X!=END CLASS) AND (# OF SUB-CLASSES OF X=l) 


THEN L1=L1+1, Return C'X.CID", "THERE IS ONE SUB_CLASS") 


EVALUATION 
FUNCTION 4: 


IF (X.Same-as!=NULL) AND 

(NOT (Z.CID=X.Same_as) AND (Z.Status="OOD")) 


THEN L1=LH-1, Return ("X.CID", "SAME AS X.Same_as")) 


EVALUATION 
FUNCTION 5: 


IF(L1<5)THEN QUALITY LEVEL = "A" 


ELSE IF(10^L1>5)THEN QUALTTY LEVEL="B" 


ELSE IF(50^L1>10)THEN QUALITY LEVEL="C" 


ELSE IF(50>L1)THEN QUALITY LEVEL="D" 


no. 21B 


RULE 1 : 


IF ISSUING OF CLASS BSU 
THEN BSU CODE="A"+MAX OF CURRENT 
CLASS BSU ISSUED No.+l 


RULE 2 : 


IF ISSUING OF ATTRIBUTE BSU 
THEN BSU CODE = "P"+MAX OF CURRENT 
ATTRIBUTE BSU ISSUED No.+l 
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FIG. 22 



c 



START J 



OBTAIN INSTANCE DRl OF DB_Revision CORRESPONDING TO 
CURRENTLY EDITED ELECTRONIC CATALOG DICTIONARY 
DATA FROM Revision Tree DATA 18 



-8501 



OBTAIN SET DR OF INSTANCES OF DB_Revision 
THAT HAS SAME VALUE AS DRLBase_version 



^8502 



YES 



Current_Num= 
DRLrevision No+1 




^503 

IS DR EMPTY SETl 

^8504 



Current_Num= 
MAX OF revision_No WITHIN DR+1 
I 



GENERATE NEW INSTANCE DR2 OF DB_Revision & 
STORE IT INTO Revision_Tree DATA 18 

• DR2.revision_No=Current_Num 

• DR2.name=DRl.name 

• DR2.date=CURRENT TIME 

• DR2.pre_revision=DRl 

• DR2.base version=DRl.base version 



8506 



DR2.File name=DR2.name+DR2.revision No+DR2.date 



GENERATE NEW INSTANCE RH2 OF Revision_History 
& STORE IT INTO Revision Tree DATA 18 
• RH2.File_name=DV2.File_name+' 'history' ' 



DR2.has_history = RH2 
I 



OBTAIN QUALITY LEVEL LI OF DICTIONARY 
SYSTEM FROM DICTIONARY QUALITY DATA 26 



GENERATE NEW INSTANCE DQ2 OF DB_quality 8l 
STORE IT INTO Revision Tree DATA IS 

• DQ2.File_name=DR2.File_name+quality 

• DQ2.1evel=Ll 

T 



'8507 
-.8508 

'8509 
8510 



'8511 



STORE DICTIONARY QUALITY DATA 26 INTO DICTIONARY 
SYSTEM QUALITY DATA 19 UNDER NAME OF DQ2.File_name 



'8512 



DR2.its_quality = DQ2 



'8513 



STORE BSU CODE CHANGE DATA 9 INTO BSU CODE CHANGE 
MANAGEMENT EDITING DATABASE 16 (FILE NAME IS RH2.File_name) 



8514 



STORE ELECTRONIC CATALOG DICTIONARY DATA 10 INTO 
ELECTRONIC CATALOG DICTIONARY EDITING DATABASE 14 

(FILE NAME IS DR2.File_name) 



8515 



C 



RETURN 



3 
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FIG. 25 Q 



START 



I 



3 



OBTAIN INSTANCE DVl OF DB version CORRESPONDING TO 
CURRENTLY EDITED ELECTRONIC CATALOG DICTIONARY 
DATA FROM Version Tree DATA 24 



S801 



Current_Num=(MAX OF version_No 
AMONG INSTANCE OF DB_version+l) 



802 



GENERATE NEW INSTANCE DV2 OF DB_Rersion & 
STORE IT INTO Version_Tree DATA 24 

• DV2.revision_No=Current_Num 

• DV2.name=DRl .name 

• DV2.date=CURRENT TIME 

• D V2 .pre_revision=DR 1 



DV2.File name=DV2.name+DV2.revision_No+DV2.date 



GENERATE NEW INSTANCE VH2 OF Version_History & 
STORE IT INTO Version Tree DATA 24 
• VH2.File_name=VV2.Flie_name+"histroy" 



DV2.has_tiistory = VH2 



OBTAIN QUALITY LEVEL LI OF DICTIONARY SYSTEM 
FROM DICTIONARY QUALITY DATA 26 



GENERATE NEW INSTANCE DQ3 OF DB_quality & STORE IT 
INTO Version Tree DATA 24 

• DQ3.File_name=DV3.Flie_name+"quality" 

• DQ3 .level = LI 



STORE DICTIONARY QUALITY DATA 26 INTO DICTIONARY 
SYSTEM QUALITY DATA 25 UNDER NAME OF DQ3.File_name 



DV2.its_quality = DQ3 



S803 



S804 



S805 



S806 



S807 



S808 



S809 



S810 



STORE BSU CODE CHANGE DATA 9 INTO BSU CODE CHANGE 
MANAGEMENT MASTER DATABASE 22 

(FILE NAME IS VH2.File name) 



S811 



STORE ELECTRONIC CATALOG DICTIONARY DATA 10 ~ 
INTO ELECTRONIC CATALOG DICTIONARY MASTER DATABASE 20 
(FILE NAME IS DV2.File name) 



c 



RETURN 



S812 
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Declaration and Power of Attorney For Patent Application 
Japanese Language Declaration 



m^-r^M^) ciiiE^tt* LZ-co 



As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated 
next to my name. 

I believe I am the original, first and sole inventor (if only one 
name is listed below) or an original, first and joint inventor (if 
plural names are listed below) of the subject matter which is 
claimed and for which a patent is sought on the invention 
entitled. 

ELECTROSflC CATALOG miNIEINIANCE SYSTEM FOR 

MABLING QUT-OF-STMDARD ELECTRONIC CATALOG 

CHANGES 

the specification of which 
S is attached hereto. 

□ was filed on 

as United States Application Number or 
POT International Application Number 

and was amended on 

(if applicable). 

I hereby state that I have reviewed and understand the 
contents of the above identified specification, including the 
claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information which is material 
to patentability as defined in Title 37, Code of Federal 
Regulations, Section 1 .56. 
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Japanese Language Declaration 

(H*MM) 



^kit. *H^^*^35«19^ (a) - (d) mXitmrn (b) 



Prior Foreign Application(s) 

P 11-332038 
(Number) 

(Number) 



Japan 



(Country) 

(H«) 



(Country) 

(lll«) 



(Application No.) 



(Filing Date) 

(ffiiaa) 



365* (c) ca-::5<«fiJ^CC{c^?SU*To S/i. ^ItiMO^ 



(Application No.) 



(Filing Date) 

(ffiMB) 



(Application No.) 



(Filing Date) 

(ttiSH) 



I hereby claim foreign priority under Title 35, United States Code, 
Section 1 19 (a)-(d) or 365(b) of any foreign application(s) for patent 
or inventor^s certificate, or Section 365(a) of any PCT International 
application which designated at least one country other than the 
United States, listed below and have also identified below, by 
checking the box, any foreign application for patent or inventor's 
certificate, or PCT International application having a filing date 
before that of the application on which priority is claimed. 

Priority Claimed 

H □ 



22 /November /1 999 
(Day/MonthA'ear Filed) 

(Day/MonthA'ear Filed) 



Yes 

□ 
Yes 



No 

□ 
No 



I hereby claim the benefit under Title 35, United States Code, 
Section 119(e) of any United States provisional application(s) listed 
below. 



(Application No.) 



(Filing Date) 

(ttiSR) 



I hereby claim the benefit under Title 35, United States Code, Section 
120 of any United States application(s), or Section 365(c) of any PCT 
International application designating the United States, listed below 
and. Insofar as the subject matter of each of the claims of this 
application is not disclosed in the prior United States or PCT 
Intemational application in the manner provided by the first paragraph 
of Title 35, United States Code Section 1 12, 1 acknowledge the duty 
to disclose information which is material to patentability as defined in 
Title 37, Code of Federal Regulations, Section 1 .56 which became 
available between the filing date of the prior application and the 
national or PCT Intemational filing date of application. 



(Status: Patented, Pending, Abandoned) 



mmx h V . ^>-^^L0A^Ltzmm t mom c ^ ^ c a cso^ 
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(Status: Patented, Pending, Abandoned) 

mM : iti^fp^v^. WM^. mmm) 

I hereby declare that all statements made herein of my own 
knowledge are true and that all statements made on information 
and belief are believed to be true; and further that these statements 
were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment, or both, under 
Section 1001 of Title 18 of the United States Code and that such 
willful false statements may Jeopardize the validity of the application 
or any patent issued thereon. 
of 3 



Japanese Language Declaration 


sett : &(JTiB®^Wift bT.*ttSffiCH•r^-^3]^0^SI# 


POWER OF ATTORNEY: As a named inventor, 1 hereby appoint 
the following attorney(s) and/or agent(s) to prosecute this 
application and transact all business in the Patent and Tradennark 
Office connected therewith: (list name and registration number) 


Norman F. Obion, Reg. No. 24.613; Marvin J. Spivak, Reg. No. 24,913; C. Irvin McClelland, Reg. No. 21'124; Gregory J. Maien Reg. No_25,599, 
Arthur 1. Neustadt. Reg. No. 24,854; Richard D. Kelly, Reg. No. 27.757; James D. Hamilton. Reg. No. 28,421; Eckhard H. Kuesters, Reg. No. 
28 870- Robert T. Pous, Reg. No. 29,099; Charles L. Gholz, Reg. No. 26.395; William E. Beaumont. Reg. No. 30.996; Robert F. Gnuse, Reg. 
NO. 27 295; Jean-Paul Lavalleye. Reg. No. 31,451; Stephen G. Baxter, Reg. No. 32.884; Richard L. Treanor. Reg. No. 36,379; Steven P 
Weihrouch, Reg. No. 32.829; John T. Goolkasian. Reg. No. 26, 142; Richard L. Chinn. Reg. No. 34,305; Steven E^ ['P""^""' 
Carl E. Schlier. Reg. No. 34,426; James J. Kulbaski, Reg. No. 34,648; Richard A. Neifeld, Reg. No. 35,299; J. Derek Mason, Reg. No^35,270, 
Surinder Sachar, Reg. No. 34.423; Christina M. Gadiano. Reg. No. 37,628; Jeffrey B. Mclntyre, Reg. No. 36.867; Wilham T. Enos, Reg. No. 
33,128 and Michael E. McCabe, Jr., Reg. No. 37,182, with full powers of substitution and revocation. 




Send Correspondence to: 

OBLON, SPIVAK, McCLELLAND, PMIER & NEUSTADT, P.C. 
FOURTH FLOOR 

i-7CK idCCPD^rtM nA\/l^5 HIGHWAY 

ARLINGTON, VIRGINIA 22202 U,S.A. 




Direct Telephone Calls to: (name and telephone number) 
^ / UO ) T- 1 o ouuu 




r uii nam© ot ooio uf iiioi juu u it ivci iwji 

Satoshi no 




inventors signaiure — ; / — ^ // , X-:^;XTr *■ 

Pf^'l^^TlA November 17,2 




Residence 
Tokyo, Japan 


mm 


Citizenship 
Japan 




Post Office Address ^ . . 
c/o Intellectual Property Divxsion, 




Toshiba Corporation, 1-1-1, Shibaiira, 
Minato-ku, Tokyo, Japan 




Full name of second joint inventor, if any 




Second joint Inventor's signature Date 




Residence 


mm 


Citizenship 




Post Office Address 








(Supply similar information and signature for third and subsequent 
joint inventors.) 
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